Remote management systems consist of a management platform in the customer device, a remote management server in the network, and a remote management protocol for communication between a management client or agent running on the management platform in the customer device and the remote management server.
An example management platform is the OSGi (Open Service Gateway initiative) service platform, which is a Java-based service platform that runs on top of a Java Virtual Machine (JVM) inside the customer device that is remotely managed. Presence of an OSGi service platform in the customer device enables remote installation, update and/or removal of bundles, i.e. software modules or components such as for instance a File Transfer Protocol (FTP) application, from an auto configuration server anywhere in the network without disrupting the operation of the customer device. This way, installation of a software application, upgrading the software application to a new version, re-configuring the application, adding or activating new features of the application, and removal of the application from the customer device, is made possible without dispatching a technician to the customer premises and without requiring an intervention by the customer. Thanks to the management platform, the software services or applications running on a single customer device can share their capabilities with each other.
The management agent or management client serves as an interface between the bundle or software application and the remote management server, and enables the management platform in the customer device to expose manageable parameters to the remote management server.
The role of the management protocol is to provide a mechanism by which the auto-configuration server can securely read or write parameter values to configure the software in the customer device and eventually monitor the status and statistics of the customer device. An example management protocol for secure remote management of customer devices is the TR-069 protocol defined by the DSL Forum in its Technical Report TR-069, entitled “CPE WAN Management Protocol”.
The TR-069 protocol is Remote Procedure Call (RPC) based, i.e. a generic message based mechanism by which the auto configuration server is able to read/write/configure parameters and parameter attributes of a software component running on a CPE device. Each parameter consists of a name-value pair. The name identifies the particular parameter and has a hierarchical structure similar to files in a directory, the different levels being separated by a “.” (dot). The value of a parameter may be one of several defined data types. Each parameter further may be defined as a read-only or read-write parameter depending on whether the auto configuration server is allowed to only read the parameter or also to change the value of the parameter.
A particular example could be an HyperText Transfer Protocol (HTTP) service or application that is installed on an ADSL or VDSL modem for client-server communications. All parameters of the HTTP application constitute the parameter model of the HTTP application. An example parameter is the number or identification of the port where the HTTP application listens to. The ADSL or VDSL modem is supposed to have an OSGi platform running on top of a Java Virtual Machine. The OSGi platform enables to share the capabilities of the HTTP application with other applications, e.g. a web browser. Via a TR-069 management agent installed on top of the OSGi platform, the parameters of the HTTP application can be made visible and accessible to an auto configuration server (ACS) in the DSL network or any other TR-069 aware bundle.
To introduce new model parameters to the auto configuration server, e.g. on installation of a new bundle, the prior art teaches three possibilities.
A first possible solution to introduce a new model parameter consists in describing the parameter through standardization. Standardized model parameters are known by standard compliant auto configuration servers and consequently can be discovered and uploaded autonomously from the customer side to the server side upon installation of the new software bundle. Obviously, this first solution takes time and consensus, and is not viable for new non-standardized or proprietary model parameters.
An alternative solution for introducing new model parameters to the auto configuration server consists in upfront defining these new model parameters, e.g. in an extended markup language (XML) file, and manually uploading the created XML file on the auto configuration server. The manual intervention of an operator however is error-prone, cumbersome and expensive.
The third prior art solution consists in defining a new attribute for the remote management protocol, e.g. TR-069, which is an additional field for one or several messages enabling to convey a parameter description, e.g. an extended markup language (XML) scheme defining the new model parameter(s), from the northbound interface of the CPE device to the southbound interface of the auto configuration server. This third prior art solution has for instance been described in contribution dsl2006.873 from Christele Bouchat and Werner Liekens for DSL Forum Specification TR69v2 or WT-148, that was entitled “Introduce a New Attribute” and submitted with the DSL Forum in March 2007. Although the latter solution does no longer require manual intervention of an operator, it is disadvantageous in that it takes adaptation of the configuration management protocol. An additional attribute has to be introduced which again takes consensus and standardization. Even if standardized, the third solution poses a problem of compatibility with deployed auto configuration servers and existing software applications which do not support the additional attribute. Another drawback of the third solution is its negative impact on the performance of the remote configuration. Indeed, as a result of the additional attribute, at least two messages have to be communicated between the CPE device and the auto configuration server in order to introduce a new model parameter to the server. First, the names and values of the parameters are communicated in response to for instance the TR-069 GetParameterValues instruction. Thereafter, the attributes including the attribute that describes the new parameters are communicated in response to for instance the TR-069 GetParameterAttributes instruction.
It is an object of the present invention to disclose an application module (or bundle) and a remote management server (or ACS) that overcome the drawbacks of the above described prior art solutions. In particular, it is an objective to disclose an application module and a remote management server able to discover new non-standardized model parameters in an automated fashion that does not require adaptation of the standardized remote management protocol and which does not impact the performance of the remote management mechanism.